The invention relates to computer systems, and more particularly to a method and mechanism for implementing transaction logging in a database system.
In database systems, a “transaction” normally refers to an atomic set of operations performed against a database. The transaction may access, create, modify, or delete database data or database metadata while it is being processed. A “commit” occurs when the transaction has completed its processing and any changes to the database by the transaction are ready to be permanently implemented in the database system. Because the transaction is atomic, all actions taken by the transaction must be committed at the same time. If any operation taken by the transaction cannot be performed, then the entire transaction must be aborted—not just the particular operation that failed. When the transaction is aborted, any changes made by that transaction to the database are “rolled back” such that the database is returned to its pre-existing state from immediately prior to the aborted transaction.
Transaction log records can be maintained to allow suitable recovery operations in the event of a system failure or aborted transaction. Some common problems that could cause a system failure or aborted transaction include hardware failure, network failure, process failure, database instance failure, data access conflicts, user errors, and statement failures in the database access programs (most often written in the structured query language or SQL).
Different types of transaction log records can be maintained in a database system. A common transaction logging strategy is to maintain “redo” records that log all changes made to the database. With “write ahead logging”, each change to data is first recorded in the redo log, and only afterwards is that change actually made to the database block corresponding to the changed data. This protects against the situation when a system failure occurs and the version of the database data that is immediately restored from disk does not accurately reflect the most recent state of the database. This may occur because of changes to the data that has only occurred in cache, and have not been recorded to disk before the failure. If redo log have been properly maintained for these cache-only changes, then recovery can be performed by applying the redo records to roll the database forward until it is consistent with the state that existed just before the system failure.
Another type of log record that may be maintained is the “undo” record, which can also be referred to as “rollback” segments. Undo records contain information about database actions that should be undone during certain database operations. For example, if the rolling forward process during recovery has applied uncommitted changes to the database, then undo records can be applied to remove uncommitted changes, thereby ensuring that only committed changes exist in the database after recovery. In addition, if a transaction is aborted, then undo records can be applied to return the database to its pre-existing state from prior to the aborted transaction. If a database uses multi-versioning to allow different transactions to view database data from different points in time, then undo records can be used to create multiple versions of the database that are consistent with the different points in time. A general approach for implementing undo and redo records is disclosed in co-pending U.S. application Ser. No. 09/748,408, entitled, filed Dec. 22, 2000, which is hereby incorporated by reference in its entirety.
In conventional database systems, a significant amount of overhead may be incurred to create and maintain transaction logs. The actions of persistently writing and storing redo and undo logs to disk requires I/O operations that may cause excessive delays and latencies in the system.
The present invention provides improved methods and systems for implementing transaction logging in a database system. In one embodiment, in-memory undo records are maintained to log undo information for the database system. In an alternate embodiment, redo records are batch processed, with multiple redo records for a transaction stored on disk at commit time. Further details of aspects, objects, and advantages of the invention are described below in the detailed description, drawings, and claims.